Since hardware resources are not unlimited, it has been suggested in the art to use content-specific filtering as a means for securing resource management in processing nodes such as routers.
Such filtering involves that not only are the application and communication protocol classified, but the content exchanged should be inspected by deep packet inspection (DPI) and packet classification functionality.
Overload protection is a requirement for most network nodes and servers. The overload could concern processor, memory and input queues. Typical servers comprise network node boards comprising multi-core processors, multiple channels memory, multiple input queue and real time operating system. Such nodes handle signalling, which is computation intensive, and data traffic, which is IO intensive. Typically, a given limit to process messages is pre-set for the processors, memory, input queues and also for real time scheduling. Excessive amounts of signalling messages could lead to processor resources being overloaded, while excessive amounts of data traffic messages could lead to input queue resources being overflowed, especially under the burst of many data traffic requests.
When an overload occurs, two consequences may be “chosen”. Either the boards/node crash due to lack of resources or packets are dropped. In both cases the node is not able to fulfil the QoS, latency or other requirements. The crash of the boards/node will cause a decreased service or complete loss of service; dropped packets will cause the system to become unstable, which will lead to a poor user experience.
Prior art document U.S. Pat. No. 2010/0067400 shows a serving gateway facing a radio access network that receives packets, applies deep packet inspect to classify the packet into a predetermined application class and inserts a marker identifying the class and a QoS associated with the class. The serving gateway assigns the packets to a queue within a default bearer based on the class and the QoS marker. The serving gateway transfers packets through the bearer by processing the queues in accordance with their priority.
Prior art document U.S. Pat. No. 7,522,581 shows server overload control methods for session initiation protocol servers. This document discusses that overload control. Overload control in general entails dropping messages in order to reduce load. Message dropping needs to happen early in the processing path of a message to minimize the amount of processing (CPU, I/O etc) resources spent on a message that will ultimately be dropped. U.S. Pat. No. 7,522,581 proposes among others the following different options for overload control: Support overload control at the network interface card (NIC) itself. While this allows a message to be dropped as early as possible, it requires additional processing support on a NIC. Another measure is to support overload control within the kernel. According to U.S. Pat. No. 7,522,581, overload control within the kernel eliminates the need for additional processing on the NIC, yet allows messages to be dropped before they are copied to the application, thus reducing the processing resources required compared to application-level support for overload control.
Prior art document U.S. Pat. No. 7,522,581 suggests a method for operating a server having a maximum capacity for servicing requests comprises the following steps: receiving a plurality of requests; classifying each request according to a value; determining a priority for handling the request according to the value, such that requests with higher values are assigned higher priorities; placing each request in one of multiple queues according to its priority value; and dropping the requests with the lowest priority when the plurality of requests are received at a rate that exceeds the maximum capacity.
Additionally, an embodiment of U.S. Pat. No. 7,522,581 is implementing a Linux Kernel. One implementation of the traffic classifier comprises four major components: 1. The classification engine itself, which parses SIP headers and maps messages to a class. 2. Interception of incoming SIP messages via TCP, UDP, and SSL and sending them to the classification engine. 3. After the incoming packet is classified, then an action is performed on this packet. 4. The configuration of the classifier and the actions to perform are transferred from user-level applications (e.g., static configuration scripts or the SIP Proxy) to the kernel.
The kernel-level classification engine operates exclusively on the tables defined in the algorithm, rather than the rules that define those tables. Supporting user-level programs convert the rule set into the tables before sending the tables into the kernel. Although the user-level compiler should create the tables correctly, the kernel performs limited verification to make sure the tables do not have invalid references.